As the use of the Internet becomes more pervasive, better technology is constantly being developed for displaying web content. Web portal pages have become an increasingly popular means of delivering aggregated, personalized content to computer users. A portal is a point of access to data and applications that provides a unified and personalized view of information and resources. Portals are typically implemented as websites on the World Wide Web and are accessible via web browser applications. Portals have evolved from simple one page content sites to multi-page aggregations of content and applications with integration to back-office systems.
Typically, a portal page is rendered and delivered to a viewing user from a portal server. The portal server includes a portal program such as WebSphere Portal Server, which is commercially available from International Business Machines Corp. of Armonk, N.Y. is loaded on the portal server. The portal program generally obtains and aggregates web content into a portal page. As known in the art, a portal page includes sections or portlets that each contain particular web content formatted according to a user's preferences. For example, a user could establish his/her own portal page that has sections for news, weather, sports, etc. When the portal page is requested, the portal program would obtain the desired web content from the appropriate content providers. Once obtained, the portal content would be aggregated, and then displayed as a portal web page. This portal technology has lead to the explosion of personalized “home” pages for individual web users (e.g., MY.YAHOO.COM).
In particular, the emerging web desktop can provide users with access to what is commonly referred to as a portal. The portal can allow a user to access multiple applications through a single screen (displayed by the web browser). For example, some portals allow users to access applications that can show disparate data, such as weather, sports, stock information, or the like, to a user on a single screen. Much of the processing needed to manage the portal (such as administration, customization, and switching) can place even greater demands on the bandwidth available between the browser and the application.
Traditionally, portals can be accessed through desktop browser applications. Browsers have been referred to as “rich clients” as browsers can provide powerful rendering capabilities, including the ability to apply style sheets to content to ensure conformity in visual appearance between applications.
Portals represent a sensible solution to the problem of aggregating content through a channel paradigm in a single, network-addressable location. In consequence, portals have become the rage in content distribution.
As mentioned, portlets are the visible active components included as part of portal pages. Similar to the graphical windows paradigm of windowing operating systems, each portlet in a portal occupies a portion of the portal page through which the portlet can display associated content from a portlet channel. Portlets are known to include both simple applications such as an electronic mail client, and also more complex applications such as forecasting output from a customer relationship management system. The prototypical portlet can be implemented as server-side scripts executed through a portal server.
From the end-user perspective, a portlet is a content channel or application to which the end-user can subscribe. By comparison, from the perspective of the content provider, a portlet is a means through which content can be distributed in a personalized manner to a subscribing end-user. Finally, from the point of view of the portal, a portlet merely is a component, which can be rendered within the portal page. In any case, by providing one or more individually selectable and configurable portlets in a portal, portal providers can distribute content and applications through a unified interface in a personalized manner according to the preferences of the end-user.
Developers have begun to apply the portlet technology for commercial applications. For example, a portal page can be used to customize a page for an employee, customer, supplier, etc. In these applications, data presented in the portlets is often related. For example, data in a “destination city” field of a travel portlet could be shared with a “target city” field of a weather portlet. In current implementations, a portlet can share data with another known portlet by using messaging or passing parameters. However, the portlet developer must have detailed knowledge of all participating portlets in order to implement the data sharing. Further, the decision of whether to share data, and what data to share is fixed when a portlet is developed. These limitations restrict the reusability and interoperability of portlets.
Portal complexity has also increased due to the growth in the number of portal users. However, tools for administering portals have not kept pace with these trends. The problem addressed is in a web portal environment, with applications running with dynamic screen content and interaction. Unlike some portal applications that deliver content that changes infrequently, application interfaces in a portal deliver rapidly changing content. As an application delivers content, accepts user input, and then launches other portlets with that context and information, several different portlets tend to build up on the screen. This is as designed and what is intended, but when these portlets present the same basic information, but with a different context, it becomes difficult to follow the chain of user interactive launches from one portlet to another and from one task page to another. This becomes confusing to user and detracts from a carefully laid out and designed interface.
A method is needed then to organize these launched portlets and task pages on the screen and allow a user to quickly and easily determine what order and what sequence led to a portal screen layout.